use dataVolumeTemplates to perform image-based provisioning by evgeni · Pull Request #178 · theforeman/foreman_kubevirt

evgeni · 2026-01-22T07:50:13Z

The current code uses containerDisk for image-based provisioning, but this results in an ephemeral disk being created on the fly, which is probably not what most users want.
This PR changes it to use a dataVolume, created using a dataVolumeTemplate (see https://kubevirt.io/user-guide/storage/disks_and_volumes/#datavolume).

While working on this, I realized that the current UI doesn't give a way to configure the resulting (root) volume when using image-based provisioning. So this PR also changes this flow a bit: a "bootable" volume needs to be configured, the details of that volume (capacity, storage class) are used for the dataVolumeTempalte created one (previously, creating a "bootable" volume while doing image-based provisioning would result in an error).

Test notes:

You'll need an DataVolume in OpenShift that you can use for copying. I was using openshift-virtualization-os-images/centos-stream9-amd64 on our CNV cluster, you can see a list of available ones with oc get datasources -n openshift-virtualization-os-images

Dependencies:

allow passing volume_templates to create dataVolumeTemplates in CNV fog/fog-kubevirt#164

app/models/foreman_kubevirt/kubevirt.rb

evgeni · 2026-01-29T09:12:36Z

test/models/compute_resources/kubevirt_test.rb

+      record.create_vm({ :name => "test", :provision_method => 'image', :image_id => "default/template", :volumes_attributes => { "0" => { :capacity => "10", :bootable => "true" } }, :interfaces_attributes => { "0" => { "cni_provider" => "multus", "network" => "default/network" } } })
+    end
+
+    test "raises an error for image based provisioning with only an extra data volume" do


this duplicates the "create_vm image based without additional volumes should fail" test below, so probably can be dropped now? (in a previous iteration of this PR this checked that a VM actually gets created correctly)

evgeni · 2026-01-29T09:13:10Z

test/models/compute_resources/kubevirt_test.rb

      record.create_vm({ :name => "test", :volumes_attributes => { 0 => { :capacity => "5" } }, :interfaces_attributes => { "0" => { "cni_provider" => "multus", "network" => "default/network" } } })
    end
+
+    test "raises an error for image based provisioning without an explicit boot volume" do


this duplicates the "create_vm image based without additional volumes should fail" test below, so probably can be dropped now? (in a previous iteration of this PR this checked that a VM actually gets created correctly)

Is this still a case? Can't find the create_vm image based without additional volumes should fail test

https://github.com/theforeman/foreman_kubevirt/pull/178/changes#diff-78ec4294c808241b6f55b2391aaa13acde29e23bc4a79fdd19d1e29490a9c133R76

(in: test/unit/foreman_kubevirt_test.rb‎)

shubhamsg199

Tested and works as expected. Able to create a host via foreman and dataVolumeTemplates is used to create the said DataVolume

stejskalleos · 2026-02-03T08:12:02Z

test/models/compute_resources/kubevirt_test.rb

      record.create_vm({ :name => "test", :volumes_attributes => { 0 => { :capacity => "5" } }, :interfaces_attributes => { "0" => { "cni_provider" => "multus", "network" => "default/network" } } })
    end
+
+    test "raises an error for image based provisioning without an explicit boot volume" do


Is this still a case? Can't find the create_vm image based without additional volumes should fail test

stejskalleos · 2026-02-03T08:15:05Z

app/models/foreman_kubevirt/kubevirt.rb

    end

-    def add_volume_for_image_provision(options)
+    def add_volume_template_for_image_provision(options)


In the UI, when provisioning a host from an image, I need to add a bootable storage disk.
But that's something users don't know they are required to do.

Should we include it in the UI as a tooltip or at least mention it in the docs?
cc @jafiala

how is that solved in other CRs? it's not like we're the first one to require a target when deploying something? :)

answering myself, vm_instance_defaults:

foreman_kubevirt/app/models/foreman_kubevirt/kubevirt.rb

Lines 221 to 226 in 34e6a25

def vm_instance_defaults

{

:memory => 1024.megabytes.to_s,

:cpu_cores => '1'

}

end

Adding :volumes => [new_volume].compact (stolen from the libvirt CR) here gives me:

No idea if setting size and boot flags by default is a good idea here as I have no knowledge where else vm_instance_defaults are used

would that make the storage class default for both image based and non image based right?

In other CRs taking example of VMware, the volume section is already added with some default size and other default fields

Yeah it would make the storage section be populated with one default volume for both provisioning methods, but it's also kinda right -- you can't provision without a (target) disk after all.

Yeah agree , we need at least one disk to be selected but also which storage class to be setted as default is a concern , as there is also a way to define default storage class in kuberneties/openshift https://kubernetes.io/docs/tasks/administer-cluster/change-default-storage-class/ and we can also check if a storage class is default or not in https://github.com/fog/fog-kubevirt/blob/master/lib/fog/kubevirt/compute/models/storageclass.rb#L33 while parsing

added the "empty" volume for now, we can enhance later

stejskalleos · 2026-02-03T08:17:41Z

app/models/foreman_kubevirt/kubevirt.rb

      raise ::Foreman::Exception.new _('VM should be created based on an image') unless image

-      verify_booting_from_image_is_possible(options[:volumes_attributes])
+      namespace, name = image.split('/', 2)


When creating the image, I believe we should update the tooltip to include an option to specify whether to include a namespace. Also, if the token works in other workspaces that are not configured on the compute resource, it works there as well. This edge case could be mentioned in the docs only.

The API help text will need to be updated as well.

Updated the help in the UI.

The API is not altered by the plugin (as the field comes from core), so can't be done there.

evgeni · 2026-02-03T13:37:42Z

Tests require

fix the mocked list_storageclasses response fog/fog-kubevirt#172

stejskalleos

My comments have been addressed, code looks good, but I haven't tested it with the latest changes.

@shubhamsg199, once you confirm the functionality, we can merge.

shubhamsg199

Ack

pr-processor bot added the Not yet reviewed label Jan 22, 2026

evgeni force-pushed the datavolume branch 3 times, most recently from 3d37370 to 0421ebb Compare January 22, 2026 10:38

evgeni commented Jan 22, 2026

View reviewed changes

app/models/foreman_kubevirt/kubevirt.rb Outdated Show resolved Hide resolved

pr-processor bot removed the Not yet reviewed label Jan 22, 2026

evgeni force-pushed the datavolume branch 4 times, most recently from 62ecc15 to d40037b Compare January 23, 2026 07:59

evgeni marked this pull request as ready for review January 23, 2026 09:28

evgeni changed the title ~~use dataVolumeTemplates to create image based hosts~~ use dataVolumeTemplates to perform image-based provisioning Jan 23, 2026

evgeni force-pushed the datavolume branch 2 times, most recently from 8ecafc0 to 5e35b8e Compare January 23, 2026 11:01

stejskalleos self-assigned this Jan 28, 2026

evgeni force-pushed the datavolume branch 2 times, most recently from 29de397 to 3d8f7e2 Compare January 29, 2026 09:08

evgeni commented Jan 29, 2026

View reviewed changes

evgeni added 4 commits February 2, 2026 14:35

simplify create_vm mocking

d9e318b

use dataVolumeTemplates to create image based hosts

eb54a9c

take first boot volume for the template if any

799b83f

require a bootable volume for image provisioning

43f58ef

evgeni force-pushed the datavolume branch from 3d8f7e2 to 43f58ef Compare February 2, 2026 13:36

Require fog-kubevirt 1.6.0+ for volume_templates support

20b3aae

shubhamsg199 approved these changes Feb 3, 2026

View reviewed changes

stejskalleos requested changes Feb 3, 2026

View reviewed changes

pr-processor bot added the Waiting on contributor label Feb 3, 2026

update image help

abfd1c7

pr-processor bot removed the Waiting on contributor label Feb 3, 2026

pr-processor bot added Needs re-review and removed Needs re-review labels Feb 3, 2026

evgeni force-pushed the datavolume branch from 75f23f0 to bfab609 Compare February 3, 2026 13:37

add default volume

ee62ff1

evgeni force-pushed the datavolume branch from bfab609 to ee62ff1 Compare February 3, 2026 13:40

stejskalleos reviewed Feb 5, 2026

View reviewed changes

shubhamsg199 approved these changes Feb 9, 2026

View reviewed changes

stejskalleos approved these changes Feb 9, 2026

View reviewed changes

evgeni merged commit 4a501b4 into master Feb 9, 2026
7 of 9 checks passed

evgeni deleted the datavolume branch February 9, 2026 12:03

evgeni mentioned this pull request Feb 10, 2026

Release 0.5.0 #182

Merged

	def vm_instance_defaults
	{
	:memory => 1024.megabytes.to_s,
	:cpu_cores => '1'
	}
	end

Conversation

evgeni commented Jan 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

evgeni Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

evgeni Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shubhamsg199 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

evgeni Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

evgeni commented Feb 3, 2026

Uh oh!

stejskalleos left a comment

Choose a reason for hiding this comment

Uh oh!

shubhamsg199 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

evgeni commented Jan 22, 2026 •

edited

Loading

evgeni Jan 29, 2026 •

edited

Loading

evgeni Feb 3, 2026 •

edited

Loading

evgeni Feb 3, 2026 •

edited

Loading